Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-034.txt

Text File | 1992-11-18 | 50.4 KB | 1,413 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 27 Mar 92       Volume 1 : Issue 34

Today's Topics:

    serial (12-tone) matrix generator
    MENU Resource ID#'s
    When does StripAddress need to be used?
    SetLineWidth PicComment problem
    Two text fields in one window, by hand?
    TextEdit:  How to Shift-Arrow-Select
    ThinkC 5 and debugger crashing!
    Very Large Arrays
    How to find/change user name?
    Newswatcher 1.0.2 bug fix


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (newton)
Subject: serial (12-tone) matrix generator
Date: 21 Feb 92 05:28:52 GMT
Organization: St. Olaf College; Northfield, MN

I am interested to know if there exists in any form, software which is
capable generating, printing and manipulating 12-tone row matrices.  I
am a composer and interested in developing such a music software tool
myself for both analysis techniques and general compositional
practice.  Because to me, it is such an obviously useful and straight
forward computer music application, I intend to take on development
for personal use.  However, something tells me there _must_ be someone
out there who has thought of this already and I would love to hear
from anyone with interest and/or results.  I would be interested in
beta testing existing software, collaborating and sharing source code,
ideas and speculations regarding this kind of program.

Anyone interested in following up on this, please contact me via email
and I will be happily respond in kind.

thanks,

************************************************************
*Dale E. Newton           [e-mail]                *
*Blue Earth Ensemble                       *
*718 Saint Olaf Ave.      507-645-6817                     *
*Northfield, MN 55057     ////////////////////////////     *
************************************************************



- -------------------------

From: [e-mail] (Cheryl Cramer)
Subject:  serial (12-tone) matrix generator
Date: 26 Feb 92 17:34:57 GMT
Organization: Computer Engineering Center, Carnegie Mellon, Pittsburgh, PA

Several years ago, I assisted in the development of a suite of programs
to generate and manipulate 12-tone material for both composition and
analysis.  These have never been formally collected into a "product" and
are probably still not very well documented, but you could get more
information by contacting:
    Dr. John Peel
    Department of Music
    Box D-158
    Willamette University
    Salem, OR 97301



---------------------------

From: [e-mail] (GILPIN, W.W.)
Subject: MENU Resource ID#'s
Date: 23 Feb 92 22:05:00 GMT
Organization: Texas A&M University, Academic Computing Services

Last night I was playing around with the menu ID's for my program. I changed
the ID's with ResEdit by using the "Get Resource Info..." dialog. Then
I changed my ID Constants in my program. Upon running my program none of my
menus worked. I checked the value for MenuSelect() and it was returning the
old Menu ID's. After about an hour of fiddling I finally figured out that in
order to accomplish what I wanted I had to change the ID in two different
places in Resedit. Why is this? I would think that all I would have to do
is change the "Get Resource Info..." dialog, like with my window and dialog
resources, but with MENU's I have to change it in the "Change ID" dialog as
well.

Wes Gilpin
[e-mail]
WWG2101@TAMZEUS



- -------------------------

From: [e-mail] (Doug McNaught)
Subject:  MENU Resource ID#'s
Date: 24 Feb 92 13:21:40 GMT
Organization: California Institute of Technology

In article <[e-mail]> [e-mail] (GILPIN, W.W.) writes:
>Last night I was playing around with the menu ID's for my program. I changed
>the ID's with ResEdit by using the "Get Resource Info..." dialog. Then
>I changed my ID Constants in my program. Upon running my program none of my
>menus worked. I checked the value for MenuSelect() and it was returning the
>old Menu ID's. After about an hour of fiddling I finally figured out that in
>order to accomplish what I wanted I had to change the ID in two different
>places in Resedit. Why is this? I would think that all I would have to do
>is change the "Get Resource Info..." dialog, like with my window and dialog
>resources, but with MENU's I have to change it in the "Change ID" dialog as
>well.

  Well, there might be a situation where you have "short" menus and "full"
menus, with the "short" being a subset. Corresponding pairs would have the same
*menu* IDs but different *resource* IDs, and you could set it up so that you
only need one dispatch routine for both types. The resource/menu ID wierdness
is a minor annoyance, but it's the kind of thing that only bites you once, and
it can be useful.
regards,
doug


--
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  MENU Resource ID#'s
Date: 25 Feb 92 03:49:04 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (GILPIN, W.W.) writes:
>Last night I was playing around with the menu ID's for my program. I changed
>the ID's with ResEdit by using the "Get Resource Info..." dialog. Then
>I changed my ID Constants in my program. Upon running my program none of my
>menus worked. I checked the value for MenuSelect() and it was returning the
>old Menu ID's. After about an hour of fiddling I finally figured out that in
>order to accomplish what I wanted I had to change the ID in two different
>places in Resedit. Why is this? I would think that all I would have to do
>is change the "Get Resource Info..." dialog, like with my window and dialog
>resources, but with MENU's I have to change it in the "Change ID" dialog as
>well.

Appropriately enough, the next article at my site was the summary of the
Mac Programming FAQ document, which includes the topic:

      What's the difference between the resource ID of a 'MENU' resource and
         the menuID field of that resource?

The summary also states the the FAQ document is "available via
anonymous ftp from skinner.cs.uoregon.edu (user name 'anonymous,' your
internet address as password) in the directory /pub/mac."

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Kent Borg)
Subject:  MENU Resource ID#'s
Date: 25 Feb 92 17:31:32 GMT
Organization: Camex Inc., Boston MA

In article <[e-mail]> [e-mail] (Doug McNaught) writes:
>  Well, there might be a situation where you have "short" menus and "full"
>menus, with the "short" being a subset. Corresponding pairs would have the same
>*menu* IDs but different *resource* IDs, and you could set it up so that you
>only need one dispatch routine for both types. The resource/menu ID wierdness
>is a minor annoyance, but it's the kind of thing that only bites you once, and
>it can be useful.
>regards,
>doug

No, short and full menus are evil, suitable only for folks like
Microsoft.  (I like to exagerate and make enemies.)

There are, however, instances where having different sets of menus can
be both useful and moral: Menus in different languages.  I recently
took this approach to internationalization of an application of ours.

At launch, our application looks at the language of the system and
sets a base resource number according to the language found (if we
don't have a localized version of the actual language we default to
English--arrogant, aren't we?).  All subsequent resource loads which
need to be changed for different languages are run through a mapping
function which adds the offset to the desired ID.  (Not that many
affected lines, I did this as a retrofit and it only took a couple
days to find and change all the resource loads, and only a few more
days to correct my mistakes.  Seems pretty solid these days.)

The menu resource IDs change with different languages, but the menu
IDs don't, so none of the calls to MenuSelect(), etc., needed any
changes.

Now, maintaining the "source" for these resources was an interesting
problem.  We use a variation on MPW's ".r" format, but with unique
flags at the head of lines which are specific to a particular
language.  This means that there is a single definition of, say, a
DITL, with single rectangle definitions, but multiple lines for
localized text, and an offset variable added to the resource ID.

We then run some scripts which preprocess this source file.  For each
language, language-specific lines for other languages are stripped
out, the language flag itself for this language is stripped out, and
the offset variable is giving the correct definition.  These different
versions are then all run through Rez.

Admittedly, this part is a bit cumbersome, but it seems to me that
maintaining different language versions of resources and keeping them
in sync is necessarily fairly cumbersome.  This scheme has the
advantage of keeping associated resources together, which ups the odds
that when the structure of one changes, the others will get matching
changes.

Finally, if the user wants to run our application in a language other
than the language of their system, the command key can be held down at
launch and the desired language selected from a dialog.  (This
feature, though not difficult to use, is obscure, but we guessed that
it would be rare for someone to not want a language match.  I assume I
am now going read postings and mail and explaining why it is
otherwise, but that is OK, it is one of the reasons I like Usenet.)

We don't change languages on the fly as does Kid Pix, but I still I
thought it was cool.

--
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me



---------------------------

Subject: When does StripAddress need to be used?
From: [e-mail] (USENET News System)
Date: Mon, 24 Feb 1992 05:18:27 GMT
Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ

The Think Pascal manual says that StripAddress needs to be called before doing
any pointer arithmetic. Is it really necessary to call it every time a handle
pointer is going to be added to, or is this just referring to pointer
comparison.

Brent



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  When does StripAddress need to be used?
Organization: Kalamazoo College
Date: Mon, 24 Feb 1992 15:04:32 GMT

In article <[e-mail]> [e-mail] writes:
>The Think Pascal manual says that StripAddress needs to be called before doing
>any pointer arithmetic. Is it really necessary to call it every time a handle
>pointer is going to be added to, or is this just referring to pointer
>comparison.

Read Tech Note 213, which explains it quite clearly.

In 24-bit mode, you usually assume the hi byte of a master pointer
contains random junk.  Normally that doesn't matter when accessing the
memory it points to, because the hi byte is ignored.  But it is
important when:

- You're comparing one master pointer to another.
- You're going to switch the machine into 32-bit mode.
- The master pointer points to a string which you're passing to
OpenResFile or OpenRFPerm (OS bug).
- You're calling some toolbox routines which don't expect their data
to move.  I got bit because I put a SndChannel in a handle;  the sound
manager stores all open channels in a linked list, and doesn't call
StripAddress before it searches for your channel.  Ben Haller (I think)
indicated the same thing for GrafPtrs--you don't want them to move in
memory, because the system'll lost track of the linked list;  but if you
put a GrafPtr in a handle, strip its address before you pass it to any
toolbox calls.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  When does StripAddress need to be used?
Date: 25 Feb 92 04:06:40 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] writes:
>The Think Pascal manual says that StripAddress needs to be called before doing
>any pointer arithmetic. Is it really necessary to call it every time a handle
>pointer is going to be added to, or is this just referring to pointer
>comparison.

Macintosh Technote #213 tries to be very clear on this. There are probably
two general cases where you need to call StripAddress:

1) If you need to do comparisons between two addresses. If you know what
   you are doing, then you don't need to call StripAddress. For
   instance, if the two addresses are generated from the same master
   pointer and you know that the tag byte of the master pointer has not
   changed, you don't need to call StripAddress.

2) The address contains non-address bits in the upper byte, and the
   address could conceivably be used in 32-bit mode.

Technote #213 gives many examples on when you should call StripAddress,
and when you _don't_ need to. In the case you state above, you will
probably not have to call StripAddress. For instance, the following
should be OK (if I remember my Pascal OK):

    myChar := CharPtr(ORD4(myHandle^) + myOffset)^;

The only time this would _not_ be OK is if you were to execute this in
32-bit mode, and myHandle belonged to a 24-bit heap. As long as you
aren't calling SwapMMUMode, or your code is not part of an interrupt
routine which could be called while someone else has switched to 32-bit
mode, you will be OK.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: [e-mail] (David Maddison)
Subject: SetLineWidth PicComment problem
Date: 24 Feb 92 20:42:05 GMT
Organization: Harvard University Science Center

SetLineWidth problem

I have been having problems using the SetLineWidth PicComment.
When I use this in accordance with TN 91 & 297. I use this Piccomment
to set the linewidth to 1/4 pixel, draw the hairline, reset the
linewidth to 1/1 pixel, but then ALL subsequent calls use a pen
width of 1/4 pixel!!!

The only way I can prevent this is by inserting (after the hairline
drawing) some dummy code that sets pensize to 4,4, draws a line, then resets
pensize to 1,1.   Note that I am not using OpenPicture to store the
picture while printing, thus the warnings in TN 297 ar------widthHdl(NewHandle(sizeOf(widthPt)));
  theWidth^^.h := 4;
  theWidth^^.v := 1;
  PicComment(SetLineWidth, SizeOf(width make an effort to remove the effects of previous SetLineWidth}
{It seems this shouldn't be necessary}
  theWidth^^.h := 1;
  theWidth^^.v := 1;
  PicComment(SetLineWidth, SizeOf(widthPt), Handle(theWidth));
{even placing another LineTo call here doesn't help}

  DisposHandle(Handle(theWidth));
  PenNormal;

{the only way to make it so that following calls do not always produce}
{hairlines is to enable code of the following sort:}
{$IFC FALSE}
  PenSize(4, 4);
  MoveTo(-100, -100);
  LineTo(-101, -101);
  PenSize(1, 1);
  MoveTo(hor, ver);
{$ENDC}

 end;

{------------------------------------------------------}
 procedure HairLineTest;
  var
   tempP: WindowPtr;
   myPrPort: TPPrPort;
   myStRec: TPrStatus;
   db: boolean;
   PgSetUp: THPrint;
 begin
  GetPort(tempP);
  PrOpen;
  if PRError = noerr then
   begin
    PgSetUp := THPrint(NewHandle(SizeOf(TPrint)));
    PrintDefault(PgSetUp);
    db := PrValidate(PgSetUp);
    if PrJobDialog(PgSetUp) then
     begin
      myPrPort := PrOpenDoc(PgSetUp, nil, nil);
      if PrError = noErr then
        begin
         PrOpenPage(myPrPort, nil);
         if PrError = noErr then
          begin
           MoveTo(100, 100);
           HairLineTo(100, 200);
           LineTo(300, 200);   {*** why is this line a hairline too? ***}
          end;
cLoop = bSpoolLoop) and (PrError = noErr) then
       PrPgSetUp, nil, nil, nil, myStRec);
      if PrError <> noErr then
       PrintErrorReport;
     end;
    PrClose;
    DisposHandle(Handle(PgSetUp));
   end
  else
   PrintErrorReport;
  SetPort(tempP);
 end;

{------  MAIN  ------}
begin
 HairLineTest;
end.

=======
David Maddison
[e-mail]

--
**********************
David R. Maddison
Museum of Comparative Zoology
Harvard University



- -------------------------

From: [e-mail] (David Maddison)
Subject: SetLineWidth PicComment Problem (repost)
Date: 24 Feb 92 21:16:40 GMT
Organization: Harvard University Science Center

(sorry about problems with previous post)

I have been having problems using the SetLineWidth PicComment. When I use
this in accordance with TN 91 & 297. I use this Piccomment to set the
linewidth to 1/4 pixel, draw the hairline, reset the linewidth to 1/1
pixel, but then ALL subsequent calls use a pen width of 1/4 pixel!!!

The only way I can prevent this is by inserting (after the hairline
drawing) some dummy code that sets pensize to 4,4, draws a line, then
resets pensize to 1,1.   Note that I am not using OpenPicture to store the
picture while printing, thus the warnings in TN 297 are not applicable.


Note also that when I spool to a file as per IM V, the lines are drawn
appropriately, with only the lines I intend to be hairlines showing up as
hairlines.  It is only when I send to the printer that things get screwed
up.

(BTW, Mac IIci, 8Mb, System 7.0 with or without TuneUp, LaserWriter IINT,
Think Pascal 3.02)

Below is the code for an entire little program that illustrates this
behavior.


Any help would be greatly appreciated.

Thanks!

David Maddison [e-mail]

=====
program HairLinesWontRecede;
uses Printing;

{-----------------------------------------------------}
 procedure PrintErrorReport;
 begin {notify user of error}
 end;

{-----------------------------------------------------}
 procedure HairLineTo (hor, ver: integer);
  const
   SetLineWidth = 182;
  type
   widthHdl = ^widthPtr;
   widthPtr = ^WidthPt;
   widthPt = Point;
  var
   theWidth: widthHdl;
 begin
  PenNormal;
  theWidth := widthHdl(NewHandle(sizeOf(widthPt)));
  theWidth^^.h := 4;
  theWidth^^.v := 1;
  PicComment(SetLineWidth, SizeOf(widthPt), Handle(theWidth));
  LineTo(hor, ver);   {draw hairline}

{now let's make an effort to remove the effects of previous SetLineWidth}
{It seems this shouldn't be necessary}
  theWidth^^.h := 1;
  theWidth^^.v := 1;
  PicComment(SetLineWidth, SizeOf(widthPt), Handle(theWidth)); {even
placing another LineTo call here doesn't help}

  DisposHandle(Handle(theWidth));
  PenNormal;

{the only way to make it so that following calls do not always produce}
{hairlines is to enable code of the following sort:}
{$IFC FALSE}
  PenSize(4, 4);
  MoveTo(-100, -100);
  LineTo(-101, -101);
  PenSize(1, 1);
  MoveTo(hor, ver);
{$ENDC}


 end;

{------------------------------------------------------}
 procedure HairLineTest;
  var
   tempP: WindowPtr;
   myPrPort: TPPrPort;
   myStRec: TPrStatus;
   db: boolean;
   PgSetUp: THPrint;
 begin
  GetPort(tempP);
  PrOpen;
  if PRError = noerr then
   begin
    PgSetUp := THPrint(NewHandle(SizeOf(TPrint)));
    PrintDefault(PgSetUp);
    db := PrValidate(PgSetUp);
    if PrJobDialog(PgSetUp) then
     begin
      myPrPort := PrOpenDoc(PgSetUp, nil, nil);
      if PrError = noErr then
        begin
         PrOpenPage(myPrPort, nil);
         if PrError = noErr then
          begin
           MoveTo(100, 100);
           HairLineTo(100, 200);
           LineTo(300, 200);   {*** why is this line a hairline too? ***}
          end;
         PrClosePage(myPrPort);
        end;
      PrCloseDoc(myPrPort);
      if (PgSetUp^^.prJob.bjDocLoop = bSpoolLoop) and (PrError = noErr)
then
       PrPicFile(PgSetUp, nil, nil, nil, myStRec);
      if PrError <> noErr then
       PrintErrorReport;
     end;
    PrClose;
    DisposHandle(Handle(PgSetUp));
   end
  else
   PrintErrorReport;
  SetPort(tempP);
 end;

{---- MAIN ----}
begin
HairLineText;
end.

=====
David Maddison
[e-mail]


--
**********************
David R. Maddison
Museum of Comparative Zoology
Harvard University



- -------------------------

From: [e-mail] (Lloyd Lim)
Subject:  SetLineWidth PicComment Problem (repost)
Date: 25 Feb 92 05:44:39 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (David Maddison) writes:
>
>I have been having problems using the SetLineWidth PicComment. When I use
>this in accordance with TN 91 & 297. I use this Piccomment to set the
>linewidth to 1/4 pixel, draw the hairline, reset the linewidth to 1/1
>pixel, but then ALL subsequent calls use a pen width of 1/4 pixel!!!
>
>The only way I can prevent this is by inserting (after the hairline
>drawing) some dummy code that sets pensize to 4,4, draws a line, then
>resets pensize to 1,1.   Note that I am not using OpenPicture to store the
>picture while printing, thus the warnings in TN 297 are not applicable.

I remember reading about this problem a while ago.  Some versions of the
LaserWriter driver interpret the arguments absolutely: 1/4 means 1/4 of
one pixel.  Some versions of the LaserWriter driver interpret the
arguments relative to the last pen size: 1/4 means 1/4 of the last pen
size.  I don't remember the version numbers.

How do you write code that works with both interpretations?  That's
an exercise left to the reader...

No really, you had the answer.  To get back to a pen width of 1,1, you'd
do two SetLineWidth calls.  The first 4,4 call works with some drivers
and the second 1,1 call works with the others but doesn't screw up the
results of the first.  You can get fancier to switch from one arbitrary
width to another arbitrary width in two calls also.

I always thought that this would be a good question to ask in a job
interview.  :-)

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616



- -------------------------

From: [e-mail] (Brad Kollmyer)
Subject:  SetLineWidth PicComment Problem
Date: 25 Feb 92 23:53:38 GMT
Organization: Vital Consulting


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (David Maddison) writes:
> I have been having problems using the SetLineWidth PicComment. When I use
> this in accordance with TN 91 & 297. I use this Piccomment to set the
> linewidth to 1/4 pixel, draw the hairline, reset the linewidth to 1/1
> pixel, but then ALL subsequent calls use a pen width of 1/4 pixel!!!
>
> The only way I can prevent this is by inserting (after the hairline
> drawing) some dummy code that sets pensize to 4,4, draws a line, then
> resets pensize to 1,1.   Note that I am not using OpenPicture to store the
> picture while printing, thus the warnings in TN 297 are not applicable.

The SetLineWidth PicComment multiples the previous line scaling factor
when you make the call. Prior to the first call the scaling factor is 1.0.
After you make a call using 1/4 you have a scalling factor or 1.0*.25=.25.
After do some drawing with the desired line scaling factor you need to reset
the scaling factor. To do this you need to use a  SetLineWidth PicComment
using 4/1 which would result in a new scaling factor of 4.0*0.25=1.0.

To sum it all up you have to remember to undo a SetLineWidth PicComment
after you are finished using a scaling factor. Hope this helps clear
things up.

Brad Kollmyer.
[e-mail]



- -------------------------

Organization: Penn State University
Date: Wednesday, 26 Feb 1992 01:42:11 EST
From: Christopher Tate <[e-mail]>
Subject:  SetLineWidth PicComment Problem

In article <[e-mail]>, [e-mail] (Brad
Kollmyer) says:
>
>The SetLineWidth PicComment multiples the previous line scaling factor
>when you make the call. Prior to the first call the scaling factor is 1.0.
>After you make a call using 1/4 you have a scalling factor or 1.0*.25=.25.
>After do some drawing with the desired line scaling factor you need to reset
>the scaling factor. To do this you need to use a  SetLineWidth PicComment
>using 4/1 which would result in a new scaling factor of 4.0*0.25=1.0.

Sadly, this is only part of the truth.  The PostScript LaserWriters do
indeed behave this way, but the non-PostScript LaserWriter (such as the
SC) do not.

On a Quickdraw LaserWriter, using a SetLineWidth PicComment with a
scaling ratio of 4/1 *always* sets the line width to 4 points, just as
using PenSize(4,4) always sets a 4-point square pen.

To get consistent results in the general case, you have to scale back to
the desired size (so that the PostScript printers are reset properly),
and then use a 1/1 SetLineWidth PicComment to make sure that the line
width is properly set on non-PostScript devices.

Generally, here's some pseudocode for using multiple high-resolution
line width definitions in sequence:

     begin
        SetLineWidth(1/4);                /* divide size by 4 */
        {draw stuff with 1/4 point lines}
        SetLineWidth(4/1);                /* scale up by 4 */
        SetLineWidth(1/1);                /* guarantee 1 point lines */

        SetLineWidth(3/8);
        {draw stuff with 3/8 point lines}
        SetLineWidth(8/3);
        SetLineWidth(1/1);

        ...
     end

And so forth.  It's *very* annoying that the behaviors are different on
different output devices; why couldn't Apple have done things in a
consistent way?

(And, isn't this stuff documented in Tech Note #91 or some such?  The one
about optimizing LaserWriter output....)

I've heard tell that Apple really hates PicComments; I'm not sure why.
If there were a more rigidly stated collection of them (like there will
hopefully be for AppleEvents), they could be a very useful tool for
dealing with PICT objects -- which IMHO are one of the Mac's greatest
features.

- -----
Christopher Tate     | Cryptogram #15:
[e-mail] |
[e-mail]  | HIPANDDZOIPOLPAU PA ZXD IDWPJPGKA NDWPDH ZXOZ
- -------------------| MXDL VGK FPD, VGKI AGKW JGDA KQ ZG ZXD IGGH
Send me the answer!  | OLF JDZA AZKBR.



- -------------------------

From: [e-mail] (Brad Kollmyer)
Subject:  SetLineWidth PicComment Problem
Date: 26 Feb 92 19:24:15 GMT
Organization: Vital Consulting


In article <[e-mail]> (comp.sys.mac.programmer),
Christopher Tate <[e-mail]> writes:
> Sadly, this is only part of the truth.  The PostScript LaserWriters do
> indeed behave this way, but the non-PostScript LaserWriter (such as the
> SC) do not.

If the printer even supports the PicComment. I know that GDT's
JetLink Express, which I wrote, supports comments like the
LaserWriter driver.

>
> Generally, here's some pseudocode for using multiple high-resolution
> line width definitions in sequence:
>
>      begin
>         SetLineWidth(1/4);                /* divide size by 4 */
>         {draw stuff with 1/4 point lines}
>         SetLineWidth(4/1);                /* scale up by 4 */
>         SetLineWidth(1/1);                /* guarantee 1 point lines */
>
>         SetLineWidth(3/8);
>         {draw stuff with 3/8 point lines}
>         SetLineWidth(8/3);
>         SetLineWidth(1/1);
>
>         ...
>      end

This would work for all printer even those QuickDraw printers that
have not implemented the PicComment like the LaserWriter driver.

Brad Kollmyer.
[e-mail]



---------------------------

From: [e-mail] (Young Rob Jellinghaus)
Subject: Two text fields in one window, by hand?
Date: 21 Feb 92 20:05:50 GMT
Organization: Autodesk Inc., Sausalito CA, USA

Oh, what a simple question this is!

For some reason I want to implement a window with two TextEdit fields
in it--sorta like a dialog box, but I don't want to use the Dialog
Manager.

Now, I know how to make the window and create the TextEdit rects and
all that.  But the question has to do with activating and deactivating
them:  let's say field 1 is active, and the user clicks in field 2.
Do I need to _first_ call TEActivate on field 2, and TEDeactivate on
field 1, and _then_ call TEClick with the event?  That is, does a
TextEdit field need to be activated before I can call TEClick on it?

Inside Mac vol. 1, and Chernicoff vol. 2, both seem to assume that
no one would ever want to put more than one TextEdit field in a window--
or that if they did they'd use the Dialog Manager.  Anyone out there
know the answer to this simple little question?  It'd be a bonus if
you could point me at a good book that answers questions like this.

--
Rob Jellinghaus                | "Next time you see a lie being spread or
Autodesk, Inc.                 |  a bad decision being made out of sheer
Internet: [e-mail] |  ignorance, pause, and think of hypertext."
AMIX: RJELLINGHAUS             |    -- K. Eric Drexler, _Engines of Creation_



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  Two text fields in one window, by hand?
Date: 25 Feb 92 20:43:19 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Young Rob Jellinghaus) writes:
>That is, does a
>TextEdit field need to be activated before I can call TEClick on it?

You would not lose your bippy if you were to bet it on this.

>Do I need to _first_ call TEActivate on field 2, and TEDeactivate on
>field 1, and _then_ call TEClick with the event?

I deactivate field 1 first, then activate field 2, then call TESomething.

NB - There's no reason in TE that you would have to Deactivate the fields
at all.  If you have some strange mutant interface where you want simultaneous
selections in multiple panes, I'm pretty sure TE will tolerate it.  (Your
users and the ATP are a whole different story, of course.)
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner



---------------------------

From: [e-mail] (James Brunner)
Subject: TextEdit:  How to Shift-Arrow-Select
Date: 25 Feb 92 15:11:43 GMT

After reading some of Inside Macintosh IV, I have a question.  Chapter #1
gives interface guidelines and explains how to select text with the
shift-arrow combinations.  The chapter on TextEdit states in the first
section that if using system version 3 or better, TextEdit will AUTOMATICALLY
handle selection via the shift-arrow keys.  How?  I would expect something
like this to have to be done via the "TEKey" routine.  However, this routine
is only passed a CHAR and the TEHandle.  The character generated by a
shift-arrow is the same as the character generated by the arrow alone.  Only
the modifiers are different - they are not passed.

How does TextEdit do it?  Does it inspect for the shift key being pressed
when the routine is called?  This could be some time after the actual
keyboard event.  Maybe there never was a keyboard event.

What's the scoop?
--
- -------------------------------------------------------------------------
Jim Brunner - ([e-mail])
All opinions are my own and have nothing whatsoever to do with BNR, NT,
NTI, Bell Canada, or any of the BCE corporations or affiliates.



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  TextEdit:  How to Shift-Arrow-Select
Date: 25 Feb 92 22:43:36 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (James Brunner) writes:

   shift-arrow combinations.  The chapter on TextEdit states in the first
   section that if using system version 3 or better, TextEdit will AUTOMATICALLY
   handle selection via the shift-arrow keys.  How?  I would expect something

It doesn't. You have to. Luckily, it isn't too hard, getting the selection,
switching on the key and then setting the selection again.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



---------------------------

From: [e-mail] (Gene Moreau)
Subject: ThinkC 5 and debugger crashing!
Organization: University of Manitoba, Winnipeg, Manitoba, Canada
Date: Tue, 25 Feb 1992 18:35:45 GMT

I seem to be having a problem with ThinC 5.02, mabey some one out there can help
me.  I am trying to write a mac shell, you know, windows, menu, etc...
It seem to be working fine when I run with the debugger turned on, but when I
turn off the debugger it hangs the whole computer and doesn't do any of the
window updates properly.  If I build it as an application then it does the
same thing and doesn't add it's name to the application menu and also hangs
the entire computer.  Am I missing something??  I am calling all the init
routines that inside mac gives in there example in IM I (all the one for the
managers that I am using, all of them that I can think of actully).
Just what am I doing wrong???
--
Gene Moreau, University of Manitoba, [e-mail]
- ------------------------------------------------------------
"Hold up a one iron and walk.  Even God can't hit a one iron"
  -Lee Traveno, on how to not get struck by lightning.



- -------------------------

From: [e-mail] (Jerry Sy)
Subject:  ThinkC 5 and debugger crashing!
Date: 25 Feb 92 20:55:07 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)


In a previous article, [e-mail] (Gene Moreau) says:

>I seem to be having a problem with ThinC 5.02, mabey some one out there can help
>me.  I am trying to write a mac shell, you know, windows, menu, etc...
>It seem to be working fine when I run with the debugger turned on, but when I
>turn off the debugger it hangs the whole computer and doesn't do any of the
>window updates properly.  If I build it as an application then it does the
>same thing and doesn't add it's name to the application menu and also hangs
>the entire computer.  Am I missing something??  I am calling all the init
>routines that inside mac gives in there example in IM I (all the one for the
>managers that I am using, all of them that I can think of actully).
>Just what am I doing wrong???
>--

Yes you are missing something.  The debugger initializes the toolbox
you are using for you, which your program probably did not.

check out which toolbox routines you are using, e.g. windows, controls,
etc and do initalize them at the start of your program (i.e. InitWindows(),
InitGraf(&thePort), InitCursor(), etc) and your program should be working
fine.

jerry sy



---------------------------

From: [e-mail] (Michael J. Tarr)
Subject: Very Large Arrays
Organization: Department of Psychology, Yale University
Date: Tue, 25 Feb 1992 19:26:46 GMT


I have been trying to run a program in THINK C 5.0.2 with a very large
array. THe system is a Quadra 700 w/ 20MB RAM.

Here is the pertinent code:

    int NumSols[1],n,p,i,j;
    FILE *fp;
    double x[LEN][M][2],ans[LEN][M][2];

    if ((fp=fopen("points.init","r"))== NULL) {
        perror("Cannot find the file 'points.init'!");
        NumSols[0] = -1; }


    fscanf(fp,"%d %d",&n,&p);
    for(i=0;i<n;i++)
        for(j=0;j<p;j++)
        fscanf(fp,"%lf %lf",&x[i][j][REAL],&x[i][j][COMPLEX]);

    if(fclose(fp)) {
        perror("ERROR in closing the DATA file");
        NumSols[0] = -1;
    }


When LEN = 16 it runs fine, but when LEN = 16000 it bombs on the fscanf.
I have both code and data far options checked...

How do I get this to run?

Please reply directly!

Mike Tarr
[e-mail]



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Very Large Arrays
Date: 26 Feb 92 10:36:17 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.yale.edu> [e-mail] (Michael J. Tarr) writes:

   Here is the pertinent code:

       int NumSols[1],n,p,i,j;
       FILE *fp;
       double x[LEN][M][2],ans[LEN][M][2];

First, the stack in a mac is never guaranteed to be more than 8K (!)
unless you foribly increase it. On color QD machines, it's at least 24K
though.

Second, compile-time-sized arrays or structs may NOT be larger than
32k; you have to allocate those run-time (using NewPtr or NewHandle
or just plain malloc)

   When LEN = 16 it runs fine, but when LEN = 16000 it bombs on the fscanf.
   I have both code and data far options checked...

Hope this helps !

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



---------------------------

From: [e-mail] (Bertrand Limoges)
Subject: How to find/change user name?
Date: 25 Feb 92 20:04:41 GMT
Organization: Sobeco Ernst & Young Inc.

I want to bring up the user name displayed in the Chooser in my
own dialog, and possibly change it from my application. I know
this is probably a no-no, but the name needs to change often and
I want to save the user having to bring up the Chooser every time.
Regardless, displaying the current Chooser name is a must, and I
can't seem to find any info in IM on the subject.

Any help much appreciated, you can email directly, Bertrand



- -------------------------

From: [e-mail] (L. Nicholas Brosnahan Jr)
Subject:  How to find/change user name?
Date: 26 Feb 92 00:32:04 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Bertrand Limoges) writes:

This is what you do:
     chooserNameH = GetString(-16096);

Look in IM I for GetString.

> I want to bring up the user name displayed in the Chooser in my
> own dialog, and possibly change it from my application. I know
> this is probably a no-no, but the name needs to change often and
> I want to save the user having to bring up the Chooser every time.
> Regardless, displaying the current Chooser name is a must, and I
> can't seem to find any info in IM on the subject.
>
> Any help much appreciated, you can email directly, Bertrand



---------------------------

From: [e-mail] (Edward J. Huff)
Subject: Newswatcher 1.0.2 bug fix
Date: 25 Feb 92 19:59:10 GMT
Organization: NYU Chemistry Dept

Newswatcher is one of three Mac newsreaders which I know of.  It is free and
comes with source.  It was written by Steven Falkenburg, [e-mail]
It is widely available from ftp sites.  So far as I know, the latest version
is 1.0.2.

This version has a problem when the main newsgroups window contains a large
number of groups.  I made a quick fix today (use two newsgroups windows)
and am posting the details to comp.sys.mac.programmer.

This problem was reported by [e-mail] (Jim Bradley) and by
[e-mail] (Dean R. Schrimpf).

Comparing the original source to my modified files gives the following
differences.  (I also added a missing return to GrowDataStructure() and
changed the percent complete calculation for "Getting groups from net"
to assume a maximum of 2000 groups instead of 1100, and why use float
when long will do?)

This was compiled under MPW 3.1.  I had to comment out include <Printing.h>
a few places to get it to compile before making any changes.

backup -r -compare only -to :orig: -from :
Compare :source:commands.c :orig:source:commands.c

File #1: :source:commands.c
File #2: :orig:source:commands.c

Extra lines in 1st before 7 in 2nd (File ":source:commands.c"; Line 7; File ":orig:source:commands.c"; Line F7)
   7    #   Modified for two Newsgroups windows 2/25/92 Edward J. Huff


Nonmatching lines (File ":source:commands.c"; Line 42; File ":orig:source:commands.c"; Line 41)
  42    /*#include <Printing.h> removed 2/25/92 EJH */

  41    #include <Printing.h>


Extra lines in 1st before 109 in 2nd (File ":source:commands.c"; Line 110; File ":orig:source:commands.c"; Line F109)
 110        (Sorting is done by the caller EJH 2/25/92)


Nonmatching lines (File ":source:commands.c"; Line 119; File ":orig:source:commands.c"; Line 117:120)
 119

 117
 118        StatusWindow("Sorting Groups...",-1);
 119        qsort(groupList, numGroups, sizeof(TGroup), MyCompare);
 120


Extra lines in 2nd before 147 in 1st (File ":source:commands.c"; Line F147; File ":orig:source:commands.c"; Line 148:159)
 148    /*  MyCompare is a comparison routine used in the call to
 149        qsort() above.  It does a simple string compare, and
 150        gives time to background applications.
 151    */
 152
 153    int MyCompare(TGroup *one,TGroup *two)
 154    {
 155        GiveTime(0);
 156        return strcmp(one->name,two->name);
 157    }
 158
 159


*** EOF on both files at the same time ***
Compare :source:nntplow.c :orig:source:nntplow.c

File #1: :source:nntplow.c
File #2: :orig:source:nntplow.c

Extra lines in 1st before 77 in 2nd (File ":source:nntplow.c"; Line 77; File ":orig:source:nntplow.c"; Line F77)
  77        return noErr;


Nonmatching lines (File ":source:nntplow.c"; Line 269; File ":orig:source:nntplow.c"; Line 268)
 269                                StatusWindow("Getting Groups From Net...",(short)(1+(((long)*numGroups)*100/2000)));

 268                                StatusWindow("Getting Groups From Net...",(short)1+(((float)(*numGroups)/1100.0)*100));


*** EOF on both files at the same time ***
Compare :source:printstuff.c :orig:source:printstuff.c

File #1: :source:printstuff.c
File #2: :orig:source:printstuff.c

Nonmatching lines (File ":source:printstuff.c"; Line 25; File ":orig:source:printstuff.c"; Line 25)
  25    /*#include <Printing.h> removed 2/25/92 EJH */

  25    #include <Printing.h>


*** EOF on both files at the same time ***
Compare :source:userint.c :orig:source:userint.c

File #1: :source:userint.c
File #2: :orig:source:userint.c

Extra lines in 1st before 7 in 2nd (File ":source:userint.c"; Line 7; File ":orig:source:userint.c"; Line F7)
   7    #   Modified for two Newsgroups windows 2/25/92 Edward J. Huff


Nonmatching lines (File ":source:userint.c"; Line 43; File ":orig:source:userint.c"; Line 42)
  43    /*#include <Printing.h> removed 2/25/92 EJH */

  42    #include <Printing.h>


Nonmatching lines (File ":source:userint.c"; Line 90:91; File ":orig:source:userint.c"; Line 89)
  90    static  WindowPtr   gGroupWindowA;
  91    static  WindowPtr   gGroupWindowB;

  89    static  WindowPtr   gGroupWindow;


Nonmatching lines (File ":source:userint.c"; Line 193:214; File ":orig:source:userint.c"; Line 191:197)
 193    /*  MyCompare is a comparison routine used in the call to
 194        qsort() below.  It does a simple string compare, and
 195        gives time to background applications.
 196    */
 197
 198    static int MyCompare(TGroup *one,TGroup *two)
 199    {
 200        GiveTime(0);
 201        return strcmp(one->name,two->name);
 202    }
 203
 204    /* SetUpWindows: creates an initial, empty window */
 205    /* Modified for two Newsgroups windows 2/25/92 EJH */
 206
 207    void SetUpWindows(void)
 208    {
 209        WindowPtr theWind;
 210        WindowPtr theWindA;
 211        WindowPtr theWindB;
 212        TwindowInfo *theInfo;
 213        TwindowInfo *theInfoA;
 214        TwindowInfo *theInfoB;

 191
 192    /* SetUpWindows: creates an initial, empty window */
 193
 194    void SetUpWindows(void)
 195    {
 196        WindowPtr theWind;
 197        TwindowInfo *theInfo;


Nonmatching lines (File ":source:userint.c"; Line 222:273; File ":orig:source:userint.c"; Line 205:239)
 222        gGroupWindowA = theWindA = MakeNewWindow(cGroup,false,firstOffset,"\pNewsgroupsA");
 223        gGroupWindowB = theWindB = MakeNewWindow(cGroup,false,firstOffset,"\pNewsgroupsB");
 224        theInfoA = (TwindowInfo *) GetWRefCon(gGroupWindowA);
 225        theInfoB = (TwindowInfo *) GetWRefCon(gGroupWindowB);
 226
 227        StatusWindow("Sorting Groups...",-1);
 228        qsort(gGroupList, gNumGroups, sizeof(TGroup), MyCompare);
 229
 230        theInfoA->numGroups = gNumGroups / 2;
 231        theInfoA->data2 = (unsigned long) gGroupList;
 232        theInfoB->numGroups = gNumGroups - theInfoA->numGroups;
 233        theInfoB->data2 = (unsigned long) (&gGroupList[theInfoA->numGroups]);
 234
 235        for (theInfo = theInfoA, theWind = theWindA; theInfo != nil; ) {
 236            theInfo->parentGroup = nil;
 237            theInfo->parentWindow = nil;
 238            theInfo->childList = nil;
 239
 240            MakeGroupList((ListHandle)theInfo->data,theInfo->numGroups,(TGroup *)theInfo->data2);
 241            SetPt(&thePt,0,0);
 242            LSetSelect(true,thePt,(ListHandle)theInfo->data);
 243
 244            GetPort(&savePort);
 245            SetPort(theWind);
 246
 247            SizeWindow(theWind,gPrefs.groupWindowSize.right-gPrefs.groupWindowSize.left,
 248                            gPrefs.groupWindowSize.bottom-gPrefs.groupWindowSize.top,true);
 249            SizeContents(gPrefs.groupWindowSize.right-gPrefs.groupWindowSize.left,
 250                            gPrefs.groupWindowSize.bottom-gPrefs.groupWindowSize.top,theWind);
 251            MoveWindow(theWind,gPrefs.groupWindowSize.left,gPrefs.groupWindowSize.top,false);
 252
 253            CloseStatusWindow();
 254            if (gPrefs.openWindowsZoomed)
 255                DoZoom(theWind,inZoomOut);
 256
 257            if (!gPrefs.groupWindowVisible) {
 258                HideWindow(theWind);
 259                RemoveWindowsMenu(theWind);
 260                SetItem(gTheMenu[kWindowsMenu],kHideShowWind,kShowText);
 261            }
 262            else
 263                ShowWindow(theWind);
 264
 265            InvalRect(&theWind->portRect);
 266            SetPort(savePort);
 267            if (theInfo == theInfoA) {
 268                theInfo = theInfoB;
 269                theWind = theWindB;
 270            }
 271            else
 272                theInfo = nil;
 273        }

 205        theInfo = (TwindowInfo *) GetWRefCon(gGroupWindow = theWind = MakeNewWindow(cGroup,false,firstOffset,"\pNewsgroups"));
 206
 207        theInfo->numGroups = gNumGroups;
 208        theInfo->data2 = (unsigned long) gGroupList;
 209        theInfo->parentGroup = nil;
 210        theInfo->parentWindow = nil;
 211        theInfo->childList = nil;
 212
 213        MakeGroupList((ListHandle)theInfo->data,gNumGroups,gGroupList);
 214        SetPt(&thePt,0,0);
 215        LSetSelect(true,thePt,(ListHandle)theInfo->data);
 216
 217        GetPort(&savePort);
 218        SetPort(theWind);
 219
 220        SizeWindow(theWind,gPrefs.groupWindowSize.right-gPrefs.groupWindowSize.left,
 221                        gPrefs.groupWindowSize.bottom-gPrefs.groupWindowSize.top,true);
 222        SizeContents(gPrefs.groupWindowSize.right-gPrefs.groupWindowSize.left,
 223                        gPrefs.groupWindowSize.bottom-gPrefs.groupWindowSize.top,theWind);
 224        MoveWindow(theWind,gPrefs.groupWindowSize.left,gPrefs.groupWindowSize.top,false);
 225
 226        CloseStatusWindow();
 227        if (gPrefs.openWindowsZoomed)
 228            DoZoom(theWind,inZoomOut);
 229
 230        if (!gPrefs.groupWindowVisible) {
 231            gPrefs.groupWindowVisible = !gPrefs.groupWindowVisible;
 232            HideShowGroups();
 233        }
 234        else
 235            ShowWindow(theWind);
 236
 237        InvalRect(&theWind->portRect);
 238        SetPort(savePort);
 239


Nonmatching lines (File ":source:userint.c"; Line 2238:2241; File ":orig:source:userint.c"; Line 2204:2205)
2238            HideWindow(gGroupWindowA);
2239            RemoveWindowsMenu(gGroupWindowA);
2240            HideWindow(gGroupWindowB);
2241            RemoveWindowsMenu(gGroupWindowB);

2204            HideWindow(gGroupWindow);
2205            RemoveWindowsMenu(gGroupWindow);


Nonmatching lines (File ":source:userint.c"; Line 2245:2248; File ":orig:source:userint.c"; Line 2209:2210)
2245            ShowWindow(gGroupWindowA);
2246            AddWindowsMenu(gGroupWindowA);
2247            ShowWindow(gGroupWindowB);
2248            AddWindowsMenu(gGroupWindowB);

2209            ShowWindow(gGroupWindow);
2210            AddWindowsMenu(gGroupWindow);


*** EOF on both files at the same time ***



- -------------------------

From: [e-mail] (Edward J. Huff)
Subject:  Newswatcher 1.0.2 bug fix
Date: 25 Feb 92 21:14:05 GMT
Organization: NYU Chemistry Dept

In article <[e-mail]>, [e-mail] (Edward J. Huff) writes:
>
> Newswatcher is one of three Mac newsreaders which I know of.  It is free and
> comes with source.  It was written by Steven Falkenburg, [e-mail]
> It is widely available from ftp sites.  So far as I know, the latest version
> is 1.0.2.
>
> This version has a problem when the main newsgroups window contains a large
> number of groups.  I made a quick fix today (use two newsgroups windows)
> and am posting the details to comp.sys.mac.programmer.
>

Use the modified version at your own risk.  I got a crash upon quit which
I have not been able to reproduce.  It probably has to do with some place
where the program "knows" that there is only one main newsgroups window.

The crash was in _InvalRect called from GetWRefCon called from DoCloseWindow
called from DoQuitStuff, or something like that.



---------------------------

End of C.S.M.P. Digest
**********************